Yep need to investigate the bundle size increase. I was hoping it would be fully wrapped due to babel-transform-react-remove-prop-types.

I was hoping it would be fully wrapped due to babel-transform-react-remove-prop-types.

We don't handle it, at least not with the wrap mode. I have been using the following pattern so far:
/~https://github.com/mui-org/material-ui/blob/6f4869af638a61acab480ccb749681aa1c4fa903/packages/material-ui/src/utils/chainPropTypes.js#L1-L5

The issue is again that we don't transpile to esmodules. Lines like
/~https://github.com/mui-org/material-ui/blob/master/packages/material-ui-styles/src/install.js#L3
will pull in the complete @material-ui/utils package. It's time to push #13391 and abandon the flat package structure for @material-ui/styles. It serves no purpose.

the flat package structure

What's the link? I agree that we should push the tree shaking story forward!

Lines like

If it wasn't for size-limit I would have changed the import.

the flat package structure

What's the link? I agree that we should push the tree shaking story forward!

If you still want to support imports via import module from '@material-ui/styles/module' that are also tree-shakeable we need to put those in a folder again with a package.json and main and module entries.

There is an alternative with *.mjs files but as far as I remember those could cause some trouble. I would like to try it out though. It's marked as alpha for a reason so we can experiment with it.

If you still want to support imports via import module from '@material-ui/styles/module' that are also tree-shakeable

Why would we want to make nested import tree-shakeable? A top level tree shakeable package sounds good enough to me.

Regarding the tree shaking. I think that we can try the react-router approach. They use a full path import where the path change between the esmodule and the commonjs version:

• commonjs: https://unpkg.com/react-router-dom@4.3.1/Router.js
• es: https://unpkg.com/react-router-dom@4.3.1/es/Router.js

Why would we want to make nested import tree-shakeable? A top level tree shakeable package sounds good enough to me.

The goal should be to make everything tree-shakeable. You don't want to bother yourself with package structure everytime you import something. If you make the top level tree-shakeable you should also make everything below tree-shakeable. You want everything that is importing something to be tree-shakeable. It's the reason why we have a bundle increase in Paper when nothing changed for that file except that @material-ui/utils increased in size. If Paper would be shakeable then webpack (or rather uglify) would be able to remove componentProp from the bundle. But since Paper is in commonJS webpack will include the full @material-ui/utils bundle.

That's one of the benfits of tree shaking. Bundle size never increases unless something observable changes. Right now it can increase if any of the packages imported in @material-ui/core/* increases its bundle size without actually changing anything.

The goal should be to make everything tree-shakeable.

@eps1lon Oh, I haven't realized that tree-shaking isn't transitive. That it will work for import { Paper } from '@material-ui/core', but not with the @material-ui/utils import that is within the Paper component 😱. We definitely need to look into that.

TL;DR: Given a file file.js import { value } from 'module'; in source. If module is in esmodule format*
and file is transpiled with esmodule format then only value will be included in the bundle. Otherwise the import statement is WRT to bundle size equivalent to import * as module from 'module';
* and module has no side-effects WRT to require

In general tree-shaking will only work (in webpack) with esmodules. The key difference is esmodules use static imports via import while commonJS uses dynamic imports via require. So webpack can identify at compile time what imports are used. For dynamic imports you you need heuristics (or config) to know what's being used and what not (prepack might be able to help here too).

So webpack knows that it can eliminate all imports in @material-ui/index except Paper if I write import { Paper } from '@material-ui/core' but when it processes Paper (in commonJS) it will use the full @material-ui/utils package because because import { componentProps } from '@material-ui/utils' will be transpiled to

var _utils = _interopRequireDefault(require("@material-ui/utils"));
var componentProp = _utils.componentProp;

and webpack will bundle the full package. It would be unsafe to shake everything else from @material-ui/utils since (see dynamic vs. static) you could write something like

var _utils = _interopRequireDefault(require("@material-ui/utils"));
var componentProp = _utils.componentProp;
var myUtilsFunction = _utils[someInputStringFromTheRuntime]; // maybe at runtime this would evaluate to 'exactProp'
// unsafe tree shaking would result in _utils: { componentProps: Function, exactProp: undefined }
myUtilsFunction(); // TypeError: myUtilsFunction is not callable 

With #13391 however this would be transpiled to (or rather no transpilation at import level)
import { componentProps } from '@material-ui/utils' and webpack would be able to shake @material-ui/utils.

I'll rebase #13391 and update eps1lon/material-ui-treeshaking. If I understood this correctly then I should be able to demonstrate the difference in bundle size on the @material-ui/utils bundle.